The present invention relates generally to data networks, and more specifically to a service locator technique implemented in a data network.
An efficient distributed computing environment benefits from having a place to store information about people, machines, and applications that are in the environment or that use the environment. When a user logs in to a computer, for example, the computer needs to find information about the user's account, such as user authentication information (e.g., password, user ID, etc.). Additionally, when the user attempts to access an application in a network, the user's machine needs to locate the server on which the application executes. While these issues can be resolved separately, a single solution is preferable.
Directory services have been developed to address these issues. A directory service typically has two main components: a database that contains the information in the directory, and protocols that are used to access that information. One example of a directory service is the Domain Name System (DNS), which primarily functions to map names to machine addresses. DNS can perform machine address lookups rapidly and efficiently. However, DNS is less effective at generalized searches relating to machines, applications or users in the network. The Lightweight Directory Access Protocol (LDAP), and the ITU X.500 directory standard from which LDAP was derived, offer more comprehensive directory services. LDAP, unlike DNS, is explicitly designed for directories that store and access complex data, i.e., data much more complex than names and machine addresses. Most contemporary directory services are based on LDAP, which is controlled by the Internet Engineering Task Force and defined in Request For Comments (RFC) 1777 (for LDAP version 2) and RFC 2251 (for LDAP version 3).
In the Microsoft® Windows® 2000 computing environment, a service called Active Directory is intended to provide a single solution to the foregoing problems and to augment the benefits of the DNS with an LDAP-based directory. Active Directory is an LDAP-compatible directory service that is intended to provide a standard way for every application to store and retrieve information in a distributed Windows 2000 environment. Detailed information about Active Directory is provided in D. Chappell, “Understanding Microsoft® Windows® 2000 Distributed Services” (Redmond, Wash.: Microsoft Press, 2000), and is incorporated herein by reference in its entirety for all purposes.
The term Active Directory Server refers to a specific installed instance of one or more software elements that implement the Active Directory service. In a Windows 2000 environment, the term “domain” may be used to refer to a set of network resources (e.g., applications, printers, etc.). Typically, domains are configured to facilitate management of access to the set of resources. Furthermore, for fault tolerance and redundancy purposes, each domain is typically controlled by multiple domain controllers (DC). Each domain controller stores and uses a complete copy of the Active Directory database for its associated domain. Active Directory allows replication, which refers to storing and synchronizing copies of the directory database on multiple domain controllers within a single domain. Replicating directory data increases availability of that data in case of system or network failures, and can improve performance by spreading client requests across more than one directory server.
Since each domain typically has two or more domain controllers, each domain controller has a complete copy of the Active Directory database for that domain. Further, Active Directory uses multi-master replication. A client can make changes to any copy of the Active Directory database on any domain controller, and the changes automatically propagate to the directory databases maintained by all other domain controllers in that domain.
In order for Active Directory to operate effectively, the replication process requires management. Active Directory uses information about “sites” and “site links” for describing the replication topology. Sites are collections of sub-networks, or subnets, with fast, reliable connectivity, which typically means high-speed LAN connections. Thus, for example, a site may comprise a plurality of Ethernets that are at the same general physical location. In addition, multiple subnets can be represented by a single high-level network prefix or “address block”. Site links are connections between sites, and typically have an associated cost. The use of sites allows clients to find the closest desired network device for a particular application. For example, the use of sites allows clients to find the closest domain controller, global catalog server (GC), distribute file system (DFS) share point or application distribution point (via Short Message Service [SMS]), etc.
A common problem associated with many large corporate IT departments relates to distributed service location techniques for providing a scaleable way to have clients and/or servers locate the closest server which is providing a particular function or service (e.g., DNS, VOD, WEB, etc.). Cisco Systems of San Jose, Calif., currently offers a Distributed Director (DD) product for implementing distributed service location functionality. Distributed Director distributes Internet services among globally dispersed Internet server sites by using information obtained from Internet router-based infrastructure, standard domain name services (DNS), and hypertext transfer protocol (HTTP).
FIG. 1 shows an example of a conventional network topology 100 which may be used to implement a recursive DNS process using Distributed Director. It is assumed in the example of FIG. 1 that the network 100 corresponds to a portion of a company wide area network (e.g., cisco.com). In the example of FIG. 1, a plurality of different logical network sites 102 are depicted. Various links (e.g. 101, 103, 105, 107) between each site are also shown, with each link having an associated cost with regard to specific routing metrics. In the example of FIG. 1, it is assumed that a user at client 108 desires to access a specific service or service provider having an associated name of “Service_A”.
As used in this application, the term service or service provider may be used to describe to a device or system which provides a specific type of service or function. Each different type of service provider may have an associated name for identifying the type of service or function provided. In the example of FIG. 1, it is assumed that a user a client 108 desires to access a service provided identified as “Service_A”. Accordingly, client 108 (whose associated IP address is 171.68.10.5) sends a DNS query to the nearest (i.e. least costly) DNS server in the network, which, in the example of FIG. 1, is DNS server 104a. The DNS query from client 108 will include a lookup request for the domain name “Service_A.cisco.com”.
When DNS server 104a receives the lookup request for the domain name Service_A.cisco.com, it recognizes the domain name as a delegated domain, and passes the DNS query to the Distributed Director device 110a. Conventionally, when the Distributed Director device receives a lookup request for a delegated domain from a particular DNS server, it will respond by providing the IP address of the closest service provider to the requesting DNS server which provides the requested service. Thus, in the example of FIG. 1, the Distributed Director device 110a recognizes that DNS server 104a is requesting the location of the closest service provider associated with the service “Service_A”. The Distributed Director device 110a has no knowledge that the DNS server 104a is requesting this information on behalf of client 108. Accordingly, the Distributed Director device 110a responds to the DNS query by providing an IP address of 152.33.2.2 to the DNS device 104a. This IP address corresponds to Service_A service provider 106b located at the London site, which represents the least costly link to a Service_A service provider from DNS server 104a. The DNS server 104a will then respond to the DNS query from client 108 by providing the IP address of Service_A service provider 106b (e.g., 152.33.2.2). Thereafter, client 108 will communicate directly with Service_A 106b, even though there is a closer, less costly service provider for Service_A at 106c. 
As illustrated in the example of FIG. 1, one problem associated with conventional service location protocols (such as Distributed Director) is that such protocols provide only limited service location functionality which do not necessarily result in locating a closest or most optimal service provider on behalf of a particular client (e.g. client 108). Additionally, another problem is that Distributed Director does not lend itself to be a programmatic interface. For example, one cannot easily use a service configured in Distributed Director to provision servers with IP addresses of the closest server.
Other protocols and methodologies (besides Distributed Director) have been proposed which attempt to provide service location functionality. Such other protocols include Service Location Protocol (RFC 2165), and Service Location Protocol, Version 2 (RFC 2608). However, these other proposed solutions do not provide true “optimal” service location, and are typically much more difficult to deploy than conventional service location techniques such as Distributed Director. Moreover, most conventional service location protocols are dependent upon real-time agents being deployed and queried in order to maintain updated network topology information. This is undesirable since it increases complexity and requires utilization of additional resources.
Based on the foregoing, it is apparent that there exists a need to improve upon distributed service locating techniques in order to facilitate communication between devices in data networks.